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ABSTRACT 

We describe the X-ray Data Acquisition and Control System (XDACS) used together with the X-ray Detection 
System (XDS) to characterize the X-ray image during testing of the AXAF Pl/Hl mirror pair at the MSFC X-ray 
Calibration Facility. A variety of X-ray data were acquired, analyzed and archived during the testing including: 
mirror alignment, encircled energy, effective area, point spread function, system housekeeping and proportional 
counter window uniformity data. The system architecture is presented with emphasis placed on key features that 
include a layered UNIX tool approach, dedicated subsystem controllers, real-time X-window displays, flexibility in 
combining tools, network connectivity and system extensibility. The VETA test data archive is also described. 

2. INTRODUCTION 

The Advanced X-ray Astrophysics Facility (AXAF) Verification Engineering Test Article (VETA) consists of the 
largest paraboloid and hyperboloid pair of Wolter type I grazing incident mirrors contained within the AXAF 
telescope and represents the first elements of the flight mirror to be manufactured. The VETA P L/H 1 mirror pair was 
aligned and tested with X-rays in the X-ray Calibration Facility (XRCF) at Marshall Space Flight Center (MSFC) 
during 1991 September and October. The alignment and PRF characterization was performed with the VETA 
X-ray Detection System (VXDS) comprised of imaging and non-imaging focal plane detectors, beam normalization 
and monitor detectors, motorized detector and aperture stages, gas control system, thermal monitoring system and 
central data acquisition and control computer system 1 . 

The X-ray Data Acquisition and Control System (XDACS) performs the control, data acquisition, monitoring, 
analysis and logging functions of the VXDS. The XDACS consists of the computers, busses, controllers and soft- 
ware required to perform these functions and is the subject of this paper. We describe the network and software 
architecture (§3 and §4), and the VETA data archive and data base used to retrieve data for detailed analysis (§5). 
A summary is given in §6. 

3. NETWORK DESIGN AND SUBSYSTEM DESCRIPTION 

The VXDS design was based on the detection system used to test the Technology Mirror Assembly (TMA), a 2/3 
scale model of the next to inner AXAF mirror 2 . The TMA test system consisted of a number of independently 
controlled subsystems, some of which were retained and incorporated into the VXDS. A key requirement of the 
VXDS design was to provide the VETA test operator with integrated procedural control and monitoring over 
all subsystems from a single central workstation. In order to meet this requirement a network architecture was 
developed that employed synchronized controllers interfaced to hardware subsystems and connected to a central 
SUN Microsystems 4/330 workstation via one of three different bus or network types: RS232, IEEE 488 or ethernet. 
A variety of bus types was required to integrate existing TMA subsystems. 

The network architecture (Figure 1) shows the central workstation and peripherals, XDACS and some XRCF subsys- 
tems, analysis workstations, busses (ethernet, IEEE 488 and RS232), external network connection and InterRange 
Instrumentation Group (IRIG) analog time signal used for synchronization. 

The subsystems shown in Figure 1 are briefly described in Table 1 and explained in more detail in Reference 1. 
The basic components and operation of the system are also described here to provide a context for the software 
description. 



Figure 1: The XDACS/XRCF network architecture combines a variety of bus types. Hardware components are 
denoted by ellipses, network components (controllers and computers) by rectangles and XDACS peripherals by 
rectangles with rounded corners. XRCF subsystems that interface with XDACS1 but were not delivered by SAO 
have dashed lines. The TMA DACS and HRI subsystems were inherited from the TMA system and are marked 
with a diagonal line. 


X-rays reflected by the VETA-I along the — x axis were detected by instruments located in the focal plane (FP). 
The FP detectors include a High Resolution Imager (HRI), a Flow Proportional Counter (FPC) and a Sealed 
Proportional Counter (SPC). The SPC and FPC are mounted on orthogonal ( y — z) motor stages behind the 
aperture plate which contains apertures of various sizes and shapes. The apertures include pinholes ranging from 
2 /im - 20 mm in diameter, annuli, and horizontal and vertical slits. The aperture plate is mounted on orthogonal 
(y — z) motor stages such that the counters are carried when the aperture plate moves. The counter and aperture 
plate motor drives constitute the Counter Aperture Translation (CAT) subsystem which is mounted on the Prime X 
and Prime Y coarse motor drives. The HRI motion is controlled by Prime-X, Prime Y and the HRI Z motor drive 
and is located in the -y direction from the CAT, along Prime-Y. A set of four quadrant shutters located at the 
entrance to the VETA-I allows X-rays in each quadrant to be blocked for mirror alignment and focus tests. The 
Prime drives, HRI-Z and shutter motors are controlled by the Test Mirror Article Data Acquisition and Control 
System (TMA DACS) subsystem. The Prime drives, CAT and FP instrumentation are collectively caHedlhe X-ray 
Detection Assembly (XDA). 

In addition to the FP detectors two Beam Normalization Detectors (BND), a large area flow and large area sealed 
proportional counter, are mounted on the BND structure located at the entrance to the VETA. The Gas Supply 
System (GSS) controls the type and flow of gas to the two flow counters and 19 thermistors located throughout 
the XDA constitute the thermal monitoring (THM) system. The central workstation and controllers constitute the 
XDACS which provides the controls and data acquisition functions for all subsystems. The X-ray Flux Monitor 
(XFM) subsystem consists of a flow and sealed proportional counter, gas system and analysis workstation and is 
used to monitor the X-ray source flux. The Motion Detection System (MDS) 3 , detects the relative motion between 
the FP instruments, VETA and X-ray source. The XDA, BND, GSS, THM system, XDACS, analysis workstations, 
MDS and XFM interfaces are collectively named the VETA X-ray Detection System (VXDS). 














Table 1: XDACS Subsystem Definition and Description 


Subs. 

Definition 

Description 

XDACS I 

XDACS2 

XDACS3 

X-ray Data Acquisition k Con- 
trol System 1 

Central controlling workstation provides operator command interface 
and displays. Issues low level subsystem commands, receives data 
and status streams, archives all data, and performs limited analysis. 
Analysis workstation. 

Analysis workstation. 

TMA DACS 

TMA Data Acquisition k Con- 
trol System 

TMA motor drive system provides movement in x, large scale y 
moves and moves the HRI in z. Four quadrant shutters located 
in frpnt_of the VETA may be opened and closed. 

CAT 

Counter Aperture Translation 

Accurate (2 /zm) motor stages move the focal plane proportional 
counters behind the aperture plate and move the aperture plate. 
The CAT is mounted on the TMA motor drives. 

HP 

Hewlett Packard 

HP 3752A IEEE488 controller contains the GSS (Ga s Supply Sys- 
tem) and THM (Thermal) monitoring system cards. The GSS con- 
trols gas flow through the Focal Plane and Beam Normalization flow 
proportional counters and the THM provides thermal monitoring at 
19 locations on the instruments, motors and structure of the XDA. 

MCA 

Multichannel Analyzer 

Controls and receives data from the FP and BND flow and sealed 
proportional counters. 

MCA PC 

MCA Personal Computer 

Interfaces with the MCA via Ortec board. Receives commands from 
and transmits data to XDACS1 via TCP/IP. 

HRI 

High Resolution Imager 

Focal plane imaging detector. 

HRI PC 

HRI Personal Computer 

Interfaces with the HRI via custom board. Receives commands from 
and transmits data to XDACS1 via TCP/IP. 

MDS PC 

Motion Detection System PC 

MDS detects relative motion between the FP instruments, VETA-I 
and X-ray source. The PC transmits TCP/IP packets to XDACS 1. 

XFM1 

X-ray Flux Monitor 1 

Workstation controls a smaller version of the MCA and HP (GSS and 
THM) subsystems. The XFM subsystem is located near the X-ray 
source and monitors the source flux. The software used to control 
and acquire data from the XFM was based on the HP and MCA 
software subsystems (little change was required). 

XMCA PC 

XFM Multichannel Analyzer 

Analogous to the MCA PC. 

XFM2 

X-ray Flux Monitor 2 

Workstation used as a display station for XFM spectra, gas and 
temperature data and status. 

XHP 

XFM Hewlett Packard 

Analogous to the HP in controlling the XFM gas system and thermal 
monitoring, but in addition controlled the proportional counter high 
voltage power supply. 

EXT NET 

External Network 

Internet network connection. 


During testing, the operator issued high level commands with appropriate parameters at the XDACS 1 console. 
Examples of tests performed by high level commands included: generation of VETA-I alignment errors using 
the quadrant shutters and FP instruments (either HRI or scanning proportional counters), beam centering with 
successively smaller apertures, encircled energy measurements and 2-D mapping of the PRF and HRI images. 

The XDACS1 acquired both autonomous and non-autonomous data during a test. For example, a 19 x 19 2-D scan 
of the PRF made with the FPC behind the 10 /im diameter circular aperture was performed by first moving the 
FPC behind the 10 ^m pinhole and then scanning the aperture plate in a 2-D raster about the current beam center. 
At each point in the scan, proportional counter spectra^were acquired in both the FP and BND counters and stored 
in files, one per point. Logs of operator keystrokes, motor positions, command parameters and low level subsystem 
commands were also generated. Upon completion of the scan the FP integrated line counts were normalized at 
each point with BND data and an image file was generated. The 361 files containing spectral data, the image file 
and logs constituted the non-autonomous data from the test. Data from the MDS, GSS and THM subsystems 
were acquired, displayed and stored continuously and independently of a given test, and were the autonomous data 


streams. 


Data acquired during testing were time stamped with either the XDACS1 clock or IRIG-B time signal depending 
on the required accuracy. The MDS data allowed time tagged events recorded by FP instruments to be corrected 
for excessive motion in the y — z plane. Synchronization to 10 ms between the MDS, HRI, MCA and XFM was 
required to support such corrections, and these subsystems accessed the IRIG time signal at the controller level via 
a PC board. Data from other subsystems were archived with ~ 1 second accuracy. We note that the stability of 
the XRCF, test benches and XDA were such that MDS corrections were never needed. 

The synchronization at the front-end controller level illustrates how the XDACS1 was isolated from direct hardware 
control. In general, the XDACS1 issu ed commands to the controllers and received back status and data streams. 
The controllers were designed to operate safely in the event of XDACS1 going off-line. Time critical data were 
transferred using TCP/IP (e.g., MDS, HRI and proportional counter data) and displayed with — 1 sec resolution 
and other data such as gas pressure or temperature were displayed after archiving with ~ 5 sec resolution. 

4. SOFTWARE ARCHITECTURE 

The software architecture is shown in Figure 2 and employs a layered structure which includes software resident 
on the hardware controller devices, low level and high level subsystem commands, procedural commands and the 
user interface including real-time displays. A brief description of each element contained within Figure 2 is given 
in Table 2. 

The software layers allow the system to be viewed with increasing abstraction typical of an object oriented design. 
Information about a subsystem is available only at the appropriate layer and complex high level commands and 
procedures are built from simpler lower level commands. For example, the hri command (or object) allows the 
operator access only to the HRI detector, and the xdamain command allows access only to the motors. The hridata 
command located at a higher level has access to both the HRI and the motors and implements the concept of an HRI 
image taken at different locations in the focal plane. The mcascan command combines the acquisition of proportional 
counter spectra (racadata), shutter motions (flapper) and motor stage motions (xdamain) to implement arbitrary 
scanning capability. The highest level commands apply specific analysis to data obtained from the lower levels 
(e.g., mcaalign calculates the mirror alignment error), or further combine functions (e.g., hrialign coordinates the 
shutter motion and HRI image acquisition, then calculates the mirror alignment errors). 

The concept of information hiding also applies to the coordinate systems found within the XDACS1 software. The 
low level xdamain program receives motor move requests in XDA coordinates which are transformed and maintained 
in the motor-specific coordinates required by the motor controllers. At the highest level, the mirror alignment errors 
are calculated by hrialign and mcaalign in the XRCF coordinate system. 

The client/server model featured in the software architecture also resulted from the object oriented design approach. 
For example, the implementation of mca ds as a server allows multiple real time displays of proportional counter 
data to execute simultaneously on workstations located in different locations. The clearly defined dependence of a 
client on a server also allows straightforward startup and shutdown sequences for the multiple processes constituting 
the system. The client/server model was also applied between the PC controllers and the SUN 4/330 using TCP/IP 
sockets. 

Commands at all levels are available to the operator from the shell. High level commands are shell scripts written in 
korn shell (ksh) that integrate low level commands typically written in C or C++. The ksh is used both as a familiar 
interface for the operator and as an integration 4GL. The string manipulation and pattern matching features of ksh 
were used to construct file names in the high level scripts and relieved the lower level C and C+-F programs from 
such manipulation. Other standard UNIX tools such as awk, be, date, wc, etc., were also used extensively. The 
UNIX philosophy was extended to provide online documentation in the “man” page format. 

The layered software architecture is extensible. New hardware subsystems may be added in a straight forward 
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Figure 2: The XDACS software architecture employs a layered structure with hardware denoted by an ellipse and 
programs denoted by squares. Arrows indicate the direction of information flow (there is no significance in dashed 
arrows other than they pass behind another box). Commands flow down the Figure and data and status flow from 
the hardware up to the displays and data archive. 


manner, often reusing code. Typical steps are (a) writing a hardware controller program, (b) creating a format 
for the archived data product, (c) writing a display/monitor program, and (d) writing the appropriate scripts to 
integrate with other existing subsystems. 

A variety of analysis software was required by both the high level software and the operator. Access to analysis 
functions is shown from the test procedure commands layer in Figure 2 and is described at the end of Table 2. The 
majority of analysis routines were developed within the Image Reduction and Analysis Facility (IRAF) environment 
and the remaining functions were coded as standalone programs. IRAF is an analysis environment used extensively 
by Astronomers for multiwavelength data reduction and analysis, and provided many of the tools required for VETA 
test data analysis. 






















Table 2: Software Module Definition 


Module 

Description 

Operator Interface Layer 

Operator Commands 

Commands are entered at the keyboard and the operator is prompted for parameters. 
Statistics and status information, in addition to real-time data, are displayed as 
commands execute. Operator may access commands from the Test Procedure and 
High/Low-level Subsystem levels. 

MCA Display 

Displays proportional counter spectra from four Multichannel Analyzer (MCA) 
buffers simultaneously in an X- window. The display program is a client of the MCA 
data server program (mca ds) and requests data every second. The operator may 
zoom on a region of interest and display specific channel counts with the cursor. 
Statistics and status displayed and updated include: counts in the region of interest, 
max and min counts, integration time and dead time. 

Motors Display 

Positions of motors are updated as commands execute. Current position, min and 
max allowed ranges and limit switch status are displayed for the three TMA motor 
stages, four CAT motor stages and four shutters. 

HRI Display 

Displays High Resolution Image (HRI) photon event data in X-window as received 
from the hri server. Operator may pan, zoom, alter color map and read pixel values 
with mouse. 

Gas/Thermal Display 

Displays gas pressures, valve status, temperatures and other status information with 
updates every 5 seconds. Parameter permitted ranges are also displayed and operator 
is required to acknowledge alarms for out of range conditions. The display program 
requests data from the hpserv server. 

MDS Display 

Displays Motion Detection System (MDS) data received from the mds server. Average 
displacements in the y — z focal plane are updated each second and displayed as a 
scatter plot and in projection. Operator may select scale of plot. 

Test Procedure Command Layer 

beamcen 

Beam centering command. Performs 1-D counter/aperture scan in y and z centered 
on current beam location. Calculates centroid of each scan, updates beam center and 
outputs plot/data sheet. Used iteratively with smaller apertures to find X-ray beam 


center. 

me a align 

Generates mirror alignment errors. Performs 2-D counter/aperture scan around cur- 
rent beam center with the four shutters opened and closed at each scan point. Builds 
four images from completed scan, calculates Pl/Hl mirror alignment tilt and focus 
errors from centroids, and outputs data sheet. Used iteratively with smaller apertures 
to provide VETA-I alignment corrections < 1 arcsec. 

meat ocus 

Generates focus error. Performs 2-D counter/aperture scan around current beam 
center with two shutters opened and closed at each scan point. Builds two images 
from completed scan, calculates the focus error, moves to new focus and outputs data 
sheet. Used to fine tune focus once alignment process is complete. 

mcafwhm 

FWHM scan. Performs 1-D counter/aperture scan around current beam center, 
calculates FWHM and outputs plot/data sheet. Used to characterize the VETA-I 


PRF V / — 

hr i align 

Generates mirror alignment errors. Acquires HRI images of the X-rays from each 
quadrant of the VETA-I by successively opening each shutter with the other three 
closed. Calculates tilt and focus errors from the centroids of each image, and gen- 
erates data sheet. Used iteratively to provide VETA-I alignment corrections > 1 


arcsec. 

hr i image 

HRI image. Acquires a single HRI image, calculates simple statistics (centroid, min, 
max) and generates a data sheet. 






Table 2: Software Module Definition (cont.) 


Module Description 




Table 2: Software Module Definition (cont.) 


Module Description 

TMA DACS The software was inherited from a previous test and was left unchanged. The tma 

and xdamain programs pass commands as strings which are executed as though they 
are typed by an operator at the TMA PC keyboard. 

HRI PC Software interfaces with the HRI electronics via a custom board and implements 

commands received via TCP/IP from the hri program. 

HP Controller The HP 3752A code is written in BASIC and applies the voltage-to-temperature 

transformation to thermistor readings, and sends and receives status from gas system 
commands. 


HDS PC Interfaces with the MDS hardware and executes the MDS da ta server process 3 . 

Other Architectural Elements 

ANALYSIS Software called by programs in the Test Procedure Commands layer. Analysis rou- 

tines were developed in the IRAF environment 4 and made available from the shell. 
File conversions into IRAF compatible formats are performed by analysis routines. 
Other analysis software available included PVWAVE and standalone programs. 

Data Files ft Logs Programs in the Subsystem Commands layer generate the XDACS1 archive data files 
containing raw and processed data e.g., raw MCA spectra, reduced 1-D and 2-D scan 
data, and raw HRI images. Logs are created at this and higher levels, e.g., gas system 
commands and alarms, all scan motor moves and operator commands. 

Parameter Files Each command is associated with a parameter file containing the current values, 
allowed ranges, type and default values of all parameters required to execute the 
command. The set of all parameter files are maintained in a single directory and 
represent a parameter data base for the entire system. The parameter files may be 
accessed through either a parameter interface library or from the command line 6 . 


5. VETA DATA BASE AND ARCHIVE 

During the VETA test a variety of data were archived by the XDACS1 including X-ray image data, proportional 
counter scan data (ID and 2D) thermal monitoring, gas system monitoring, motion stability measurements and 
other logging data. 

The VETA test data archive was created during the VETA test as shown in Figure 3. Raw data streams were 
received from the various subsystems, processed and stored as formatted archive data. HRI and MCA X-ray data 
were stored together with a set of header keywords containing information about the data and test environment. 
Examples of header keywords include date, start time, finish time, integration time, operator, peak counts and 
filename. In the case of MCA scan tests two levels of data file were stored: raw spectra (one file for each point 
in the scan) and reduced scan data files containing the integrated counts as pixel values. In both cases header 
keywords were stored together with the data. The scan pixel values derived from the raw spectrum during the test 
represent “quick look” analysis since the integrated counts were derived by simply summing counts in a region of 
interest rather than correcting the spectrum for known physical effects. 

In addition to the quick-look analysis performed during testing, more rigorous reduction and analysis was performed 
post-test that required flexible access to the archive. A set of data bases were constructed containing the header 
keywords generated during the test and information derived from the data file attributes. Data base queries typically 
generate a list of X-ray data filenames and their location within the archive. 

The data base is comprised of four data base files in ASCII /rdb format: 


• mcahriscn: common fields to both HRI and MCA data bases 




Figure 3: The VETA test data archive was constructed during the testing from both autonomous and non i 
tonomous data streams. 

• hriscn: HRI image file keywords 

• mcascn: MCA scan file keywords 

• mcapch: MCA raw proportional counter spectra keywords. 

There are numerous fields in the data base, for example the names of the first 10 fields (of 79) within the “mca-scn 
data base are: scanld, apsize, aptype, bchanO, bchani, counter, date, dcain, dcamv and dcbin 

Queries are made using /rdb in the UNIX environment, for example the command: 

column date filename aptype < mcascn I row 9 aptype==" annulus" * 

selects the fields “date”, “filename” and “aptype” from the mcascn database and then selects only those rows with 
the aperture type of “annulus”. In this example the commands “column” and “row” are /rdb commands. 

Archive extraction functions were developed to retrieve subsets of autonomous data sets such as gas system, thermal 
and MDS data. These subsets are combined with the data files accessed through data base queries to construct 
time correlated test data sets. The process is usually performed automatically using a shell script. 

6. SUMMARY 

We have presented the network and software architecture of the X-ray Data Acquisition and Control System used to 
control, archive and display data during the AXAF VETA-I X-ray test. The key features of the network architecture 
include: diverse hardware subsystem control from a single SUN workstation, isolation of critical functionality on 





front-end controllers, integration of a variety of bus types and extensibility. The key features of the software 
architecture include: layered object oriented design, access to commands at all layers, client/server model, use of 
ksh for 4GL integration and extensibility. The VETA test data base provides convenient access to data stored in 
the data archive from the UNIX shell. 

The VXDS system will form the basis for the next generation of equipment for testing of the assembled AXAF flight 
mirrors and science instruments. The software and network architecture developed for the VXDS system proved 
robust and will be extended to accommodate the new hardware anticipated for the next generation system. 
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